A quick and clean guide to set up your Raspberry Pi Zero 2 W headlessly with Wi-Fi, SSH, and a static IP – perfect for IoT and embedded projects.
Discover gists
Cross-variant comparison of VBIOS structure and configuration across the GA100 product family. Sourced from static binary analysis of ROM dumps + empirical flash experiments + Lapsus Booter disassembly.
Last updated: 2026-05-31 (Drive A100 PG199 VBIOS dumped and analyzed)
Contributors: Petri Krohn (ECB cryptanalysis, RFRD manifest decode, known-plaintext identification), Cab (ECB padding block confirmation, ImHex structure labeling, license region offset discovery via gpuio BAR0 dump)
This bot trades Polymarket's "BTC Up or Down" 5-minute binary markets. Every 5 minutes, Polymarket opens a market asking: "Will BTC be higher or lower than the opening price when this 5-minute window closes?" You buy "Up" or "Down" tokens at some price (e.g. $0.50–$0.95), and if you're right, each token pays out $1.00. If you're wrong, you lose your bet.
The bot uses technical analysis on real-time Binance BTC price data to predict the outcome, then places the trade on Polymarket right before the window closes — when we have the most information but (ideally) before the token price has fully priced in the outcome.
Some support LinkedIn import.
A curated list of awesome PostgreSQL software, libraries, tools and resources, inspired by awesome-mysql
PostgreSQL, often simply Postgres, is an object-relational database (ORDBMS). PostgreSQL is ACID-compliant and transactional. (see more: wikipedia:PostgreSQL, PostgreSQL.org)
🐘 Contributions welcome. Add links through [pull requests](https
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
- There are always 24 hours in a day.
- February is always 28 days long.
- Any 24-hour period will always begin and end in the same day (or week, or month).
Writing Great Unit Tests: Best and Worst Practices by Steve Sanderson
This blog post is aimed at developers with at least a small amount of unit testing experience. If you've never written a unit test, please read an introduction and have a go at it first.
What's the difference between a good unit test and a bad one? How do you learn how to write good unit tests? It's far from obvious. Even if you're a brilliant coder with decades of experience, your existing knowledge and habits won't automatically lead you to write good unit tests, because it's a different kind of coding and most people start with unhelpful false assumptions about what unit tests are supposed to achieve.
Most of the unit tests I see are pretty unhelpful. I'm not blaming the developer: Usually, he or she just got told to start unit testing, so they installed NUnit
Note: This is an old post from back when I was trying to make sense of why inets are so fast for evaluating some λ-terms. It has some silly bits, I learned a lot since and could probably write a better article today, but I think this can still be insightful for these getting started, so I'll leave it here.
Yesterday, I reported the bizarre observation that certain functions can behave as if they had negative complexity. If you haven’t checked that article yet, it isn’t necessary, but you should, as it may blow your mind. In short, the λ-term f(bits) = copy(comp(inc,n,bits)), when given to optimal λ-calculus evaluator, is asymptotically faster than g(bits) = comp(inc,n,bits); i.e.,copy (a O(1) operation for a fixed size) behaves as if it had a O(1/n) complexity, causing the program to run faster by doing more things (!?).
That’s not the only bizarre complexity result I had when
| # Chrome OS recovery images manual download | |
| https://dl.google.com/dl/edgedl/chromeos/recovery/recovery2.json | |
| https://dl.google.com/dl/edgedl/chromeos/recovery/recovery.json | |
| # Google Chrome OS Flex images manual download | |
| https://dl.google.com/dl/edgedl/chromeos/recovery/cloudready_recovery2.json | |
| https://dl.google.com/dl/edgedl/chromeos/recovery/cloudready_recovery.json |
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.